It's too late for me to actually try to understand this, but have you looked at Erlang at all? P2P type clustering to form redundant applications spanning multiple systems is pretty natural in Erlang.
This is false by any definition of strong typing I've seen. This isn't even something one can have an opinion on, it's just wrong.
Portrait of a strongly typed language:
>>> a="some string" >>> a + 5 Traceback (most recent call last):
File "", line 1, in ? TypeError: cannot concatenate 'str' and 'int' objects
In a weakly typed language (i.e. perl), the statement will just break in mysterious ways:
$a="some string"; $a = $a + 5;
print "$a\n";
(prints 5)
See also dynamic typing and static typing (python is dynamically and strongly typed. It breaks when you do stupid stuff like that, but not until runtime. Ocaml is statically and strongly typed. It breaks at compile time when you try to do stupid stuff like that).
Yes, the DAV means that but its not currently implemented.
Sure, but the original point was that WebDAV would bypass all of the revision control needs. If WebDAV (which was designed for this) fails to do it due to implementation deficiencies, then the implementations need to catch up.
Warning: mysql_connect(): Can't connect to MySQL server on 'nexus' (113) in/home/sites/public_html/diracian.com/system/databa ses/mysql.class.php on line 108
Cannnot connect to DB server
Between PHP and mySQL, I don't much like this one.
WebDav is not the ideal solution, because it completely undermines the check-in/check-out process. It's like having a workorder system but no CVS for your code.
Just so you know, the DAV part of WebDAV stands for ``Distributed Authoring and Versioning.''
In my experience, it's one of those "it would be a wonderful thing if it worked."
I've been using it for years. I've found nothing that works better. I've got ``clients'' that are IRIX, NetBSD, Solaris, SunOS 4, NetBSD, MacOS X and FreeBSD and I use it to serve my web root, home directories, various applications (my mail server etc...) I can't imagine using something else.
It requires it's own partition for each mount of it; you can't just share disks you've already got.
This is very misleading. A file server has to have a dedicated partition. Clients need nothing but OpenAFS or similar installed. Mount points are global and management is distributed. Thinking that AFS is anything like NFS would certainly lead to a bad experience. It solves many, many problems with NFS.
The servers time has to be matched exactly, so it's also best if you've got an NTP server running and clients on all the machines.
And your AFS server and client comes with them. I can't imagine what the problem would be with having times matched, anyway. I've gone through the horrors of tracking down log entries from systems that didn't have time synchronized. I don't want to do that again.
It's also about ten times slower than Samba (which you might use instead to share with Windows machines), and it chokes when you try to move/copy/delete large files.
Slower at what? Access times? Add another server, it's not like you have to tell the clients. Write times? I don't know about that, I wouldn't want to run a database off the thing, but that's not what it's for. I have no idea what you're talking about regarding it choking on large files. I haven't seen that.
I tried it for a month before it completely corrupted it's own partition and I switched back to NFS and Samba.
How exactly did it corrupt its own partition? I've never seen such a thing. Perhaps you did something you were not supposed to do (like anything in its own partition).
I can't wait for the day when these problems are but a memory and such a system works flawlessly.
There have been some *very* large AFS installations for years (MIT, CMU, etc...). I wouldn't think that would be the case if such problems were common.
CGI in-process, using mod_perl or mod_caml, with database connection caching.
(Obviously? Surely no one in 2003 would be advocating forking and connecting to the database?)
Well, that's pretty much what CGI means. The CGI specification includes details like commandlines, environment variables, stdin, stdout, etc...
When I say a well-written CGI will be slower than a well-written servlet, I'm referring to a CGI as defined in the cgi specification. mod_perl is not used for writing CGIs, it's used for making CGIs that use CGI.pm run more quickly. CGI.pm makes a reasonable abstraction layer ehre that allows one to write something written properly to work either way.
There is also FastCGI which overcame some of the limitations of CGI, but applications typically need to be written differently to operate this way.
So, no, it's not really obvious when you use terminology that has a specific meaning when it's not the meaning you're trying to convey.
Re:Worth Learning?
on
Bitter EJB
·
· Score: 2, Insightful
Firstly I've written mod_caml which is, you'll be disappointed to know, an interface to the Apache API from Caml.
I'm a little confused by the point of this statement. Why am I disappointed to know this?
Secondly, OCaml isn't just a compiled language.
Well, no, it's got a repl, but that would seem to defeat the purpose of the static typing.
Thirdly, if you'd ever written a website you'd know that queries on the database dominate. Interpreted, compiled - it makes no difference.
You left out the word ``badly'' in the first sentence. Putting a lot of the work on the DB limits scalability dramatically. I had to deal with these issues at my current job. Everything that wanted data, no matter how static, would request it directly from the DB at the point it needed it. We had horrible scalability problems and couldn't get a DB server big enough to handle our load about a year ago. Now, with approximately 8-9 times more traffic, things are typically 12 times faster.
A well-written CGI will be less efficient than a well-written servlet, especially under load.
This is plainly wrong.
It's my experience, mostly due to the ability to pool and cache data, as well as perform asynchronous parallel processing even after the client disconnects, freeing resources for the next guy. It also helps to be able to perform a good deal of initialization before the first client talks to you and holding onto that state for a while rather than trying to figure out what to do every time a client makes a contact with you.
I mean, just from a syscall point of view, I don't have to fork/open/read/close/connect/close to figure out where my database is and connect to it. Not to mention the overhead of actually parsing the config and authenticating with the DB.
Why do you believe that a CGI is more efficient?
Re:Worth Learning?
on
Bitter EJB
·
· Score: 2, Insightful
EJBs, and Java in general, are almost always entirely the WRONG approach to producing websites.
EJBs usually, java, no. The servlet architecture is one of the best things to happen to web development as far as making highly scalable web applications.
To make an efficient site, use a scripting language like Perl [or OCaml, but I declare an interest in that], write CGIs, use mod_perl to make it run efficiently, and where you want to optimise, put your logic into stored procedures. Templating and SSIs are also useful.
This is amazingly wrong.
First, OCaml's a compiled language, not a scripting language.
Scripting languages do not make a site more efficient. They might make the developer prototype more efficiently, but they aren't going to run more efficiently than something that's compiled, and in many cases, they'll provide you with surprising results later on.
Even then, I often write my struts actions in python for development. I've got a struts action that allows me to write them in python or bsh, which saves a ton of development time at the cost of runtime efficiency. Being able to write a two-line struts action is nice, though. These should be ported to java before I expect to them to handle load, though.
A well-written CGI will be less efficient than a well-written servlet, especially under load.
mod_perl is great if you can stand to write perl, and can do it carefully, but there are plenty of problems with doing this.
Putting your logic in a stored procedure will give you the opposite of scalability. The database is generally the most expensive resource in an application, and is the most difficult to distribute. You want your logic as far away from this as you can possibly get it.
Not as many third party specifications to learn. I remember having to learn Struts, Ant, Tomcat, and then Sophia after learning JSP - what a pain in the ass.
You would consider it a feature that there aren't third-party tools to improve development and deployment?
I have no idea what Sophia is, but I used java for a long time before hearing of struts and ant (you know, you can use Make with java). Struts takes the generic specs and makes things a lot better. They're both optional. Like many other misguided souls, I've written apps completely in jsp as well.
Third-party options that fit into standards, make things better, but are not required are an advantage, not a disadvantage.
Well then how about the "open source guys" shoudl stop posting articles about how much better linux is than windows. After all,w e wouldn't want ot make any Windows user's life easier, even if it did mean liberating them from free software.
I didn't mean to imply that we don't want Windows users' lives to be easier. The amount of effort it takes to suggest an alternative platform is far less than the amount of effort it takes to make sure my software works on one I consider inferior, though.
By your description, those Apache HTTP server folks are a bunch of seelouts, because I'm running their product on this very Windows XP box. Those bastdards! Who do they think they are making this Windows user's life easier? And they're not alone. Many Java, Python, Perl, etc. oppen source projects are also cross-platform. They're all readily cross-platform.
Windows users took the time to port Apache to Windows. Same for any other open source app that got ported to Windows (java does *not* count). If I don't use Windows, why would I go out of my way to make sure you can? I'll take your patches if they're good and don't conflict, but I'm not going to waste my time on something I'll never use.
So I know you said you weren't trying to be rude. It's just that your point-of-view (windows users are evil and should be left to rot untilt hey take the leap of faith that is Linux) conflicts with other views (we need to hurt Microsoft by taking away their customers by any means necessary).
Anyone who has any goals remotely like this is hopefully going to be making money from them. My goal is to write good software that serves me well. If it servers others well, all the better.
Yes, but gradually and comfortably. If open source guys could focus on cross-platform stuff, it would be a smoother transition. I could switch out my PIM now, for example, and take it with me when I'm ready for the Linux plunge. At least compatible data formats.
We open source guys aren't working for you. Personally, I have no interest in writing any software to make people's lives any better when they're on Windows. If you want this, you do it.
I'm not trying to be rude or anything, but you're talking about free software. If your only contribution is telling them that you want them to go through extra effort to make sure their software works in Windows, I doubt you'll get far.
My RSS feeds have broken randomly for as long as I've had the thing up. It's given me the opportunity to come up with a really robust design for it, though.:)
There's a really handy module called "Fatal" which you can use to make any existing function throw an exception if it returns a false value. For example:
use Fatal qw(open close);
This is very informative and something every perl programmer should know and use.
I, however, will be sticking to languages that don't require me to remember to mark every function that might fail as something that should throw an exception on failure and will just do it by the way stuff in the language is designed. I don't want to have to remember the way to get DBI throwing exceptions, IO stuff throwing exceptions, etc...
My Perl code uses exceptions extensively. It's not necessary for me to check return codes. I think you are generalizing based on one way to write Perl code.
Perl's file IO, DBI, etc... make no use of exceptions. You have to build your own abstractions to do this. Python, ruby, java, ocaml, (etc...) use exceptions at the lowest level available to the programmer.
Slashdot's code is not very elegant. This is not Perl's fault.
I disagree here to a degree. Languages have cultures and idioms that are built around them. If a language makes it easier to do something in a bad way, then it's most likely to be done in a bad way (or it'll be hard to work with).
For example: Perl, like C requires you to check results of most things you do to verify they worked. That's a ridiculous way to write anything of any complexity. If I say something should happen, it should just happen. If it can't happen, *then* let me know about it. Good code in a language that uses exceptions natively looks like ``bad'' code in a language that requires you to do the work yourself...meaning the programmer will likely express what he wants to happen and then move on. If exceptions are a core part of the language, the application will go to an exception handler as soon as something ``goes wrong.'' You have to specifically prevent this from happening.
Compared to having to specifically validate every operation you do and plan a path out even for really unlikely cases, it's a lot easier to write reliable applications in langauges like python, java, ocaml, etc...
I would say that caching search results in the session is a big mistake. First, what if the user opens multiple browser windows? They will get crazy results if they try to run multiple searches and page through them, and this is a fairly common scenario for most sites. I think you'd be much better off using a file-based search results cache with the search criteria as the key (rather than the session ID).
Well, likewise, I could pass the search ID around through all the pages if I wanted to deal with that scenario. There's no file IO required for every re-sort.
MyISAM tables have no transactions, so you are basically talking to an in-memory multi-threaded daemon over a local Unix domain socket.
UNIX domain socket means the machine with the app server has to be running the database. It also means that there's no failover for the session. A DBM would be better at this point (map key to structure, read and write structure at request/response time).
Programmers like other professionals need to establish a sense of professional elitism. PHP is a language that just about anyone can use, and when you have something that just about anyone can do, then you won't get the big bucks.
It's not so much elitism as it is experience. I work on project lifetimes these days. I want most of the work up-front so I can move on to other things. Whatever little savings PHP might get me up-front is of little value over the lifetime of the project.
The end result, PHP/MySQL is what people use when they want to get a job done, Java/XML is what you use if you want to build a career.
That sounds like consultant mentality. It makes sense if your goal is to produce a working model that will look good at the end of a contract, after which you will never see it again...and who cares if it is difficult to maintain?
I guess your information is not very important since it can be wiped out by a power down or crash between the confirmation and the asynchronous background write.
In my app, I've got somewhere over a half a million clients that come talk to me every day and tell me how things are, ask what's new, etc... I track various aspects of this information in a couple different databases. If I don't save information for a guy today, I will tomorrow. In cases like this, async transactions get the user back on his way very quickly and I rarely miss a save. If I do, big deal.
I also do asynchronous saves in my photo album app (photoservlet.sf.net), but I do it a different way. In that application, there is a cache of structured image data that is used for putting up the pictures, but the image data also gets stored in the database. When a new picture comes in, I immediately structure the data and cache it for viewing, and then write a couple of records indicating the data has arrived. Within a few seconds, a thread will notice the changes and begin storing the image data into the DB (which takes too long to make a user wait).
This is an example of asynchronous transactions done safely while still giving the appearance of a faster application.
It's VERY hard to go faster than MySQL with MyISAM tables for this kind of simple shared data.
Sure, for small numbers of servers sessions and requests. My application server farm contains eight systems. Intelligent routing means that you're most likely going to go to the server that has your session state in a Map in memory. When it's a single map lookup to find your session, and then a map lookup for anything out of your session, that's pretty much as fast as you can theoretically get.
Replication of the session involves the container serializing the Map and passing it to one server in the cluster that is defined as its secondary. This means your session is replicated once so that if your master server fails, the session routing will take you to the secondary server (and if it fails, you lose your session).
Sometimes, you need large sessions, though. My application has a search which can return, at most, 200 results. My search UI allows you to page through those results (randomly or sequentially), change the sort order, etc... Any operation (after the initial search) is nearly instant. It's also consistent. You don't hit the next page and suddenly see duplicate results, or miss results because the source data changed.
In this example, a larger session makes everything better. Hitting a DB every time someone wants to go to page 2, or sort by last name or whatever would be slower, regardless of what type of table you use in your mySQL DB.
(OT: upon trying to submit this message:
500 Internal Server Error
An internal server error occurred. Please try again later. )
Perl seems to scale as well--it runs a very busy site [slashdot] I frequent with few problems.
I've been having a great deal of broken pages lately.
I also have been having a lot of problems with the RSS feeds lately.
Overall, I like using slashdot as an example of why mySQL and perl are bad ideas for busy sites.
Any language can be used to write bad code, but I've rewritten really perl projects (2M line range) that were impossible to maintain into java (for example) applications that were not only easier to manage, but performed better.
Whether raw perl is faster than raw java, who knows or cares? When I want raw speed, I write apps in ocaml (or C if I need slightly more speed). When I want to prototype something quickly, I write apps in python. When I want to build a large scale application, I use java (and python for parts). With a proper design, going from one application server to two doesn't double the strain on my database server (not even close), but usually doubles my capacity. It also doesn't require a rewrite of the app.
Then I start making things happen asynchronously with threads and message queues. These days, my apps are looking more like mainframe apps from performance monitors. We maintain a pretty high load here, and I watched it triple during some event for a few minutes. Processing speed was constant due to surge protection I was able to make using a simple thread and a linked list. For our most common type of database work, there is no more than one insert/update occuring per application server instance. That makes such a huge difference.
Slashdot Mirror
It's too late for me to actually try to understand this, but have you looked at Erlang at all? P2P type clustering to form redundant applications spanning multiple systems is pretty natural in Erlang.
Python is far from being strongly typed.
This is false by any definition of strong typing I've seen. This isn't even something one can have an opinion on, it's just wrong.
Portrait of a strongly typed language:
>>> a="some string"
>>> a + 5
Traceback (most recent call last):
File "", line 1, in ?
TypeError: cannot concatenate 'str' and 'int' objects
In a weakly typed language (i.e. perl), the statement will just break in mysterious ways:
$a="some string";
$a = $a + 5;
print "$a\n";
(prints 5)
See also dynamic typing and static typing (python is dynamically and strongly typed. It breaks when you do stupid stuff like that, but not until runtime. Ocaml is statically and strongly typed. It breaks at compile time when you try to do stupid stuff like that).
Yes, the DAV means that but its not currently implemented.
Sure, but the original point was that WebDAV would bypass all of the revision control needs. If WebDAV (which was designed for this) fails to do it due to implementation deficiencies, then the implementations need to catch up.
Between PHP and mySQL, I don't much like this one.
WebDav is not the ideal solution, because it completely undermines the check-in/check-out process. It's like having a workorder system but no CVS for your code.
Just so you know, the DAV part of WebDAV stands for ``Distributed Authoring and Versioning.''
RRD TOOl (sp?) is the successor to MRTG I beleive wich allows the graphing of numerous values, limited only be the clutter created in the graph.
rrdtool is the collection/graphing component. Newer MRTGs just use it. You can do very cool stuff with it.
Damn, I *almost* hit preview. :) Oh well. Sorry about that.
In my experience, it's one of those "it would be a wonderful thing if it worked."
I've been using it for years. I've found nothing that works better. I've got ``clients'' that are IRIX, NetBSD, Solaris, SunOS 4, NetBSD, MacOS X and FreeBSD and I use it to serve my web root, home directories, various applications (my mail server etc...) I can't imagine using something else.
It requires it's own partition for each mount of it; you can't just share disks you've already got.
This is very misleading. A file server has to have a dedicated partition. Clients need nothing but OpenAFS or similar installed. Mount points are global and management is distributed. Thinking that AFS is anything like NFS would certainly lead to a bad experience. It solves many, many problems with NFS.
The servers time has to be matched exactly, so it's also best if you've got an NTP server running and clients on all the machines.
And your AFS server and client comes with them. I can't imagine what the problem would be with having times matched, anyway. I've gone through the horrors of tracking down log entries from systems that didn't have time synchronized. I don't want to do that again.
It's also about ten times slower than Samba (which you might use instead to share with Windows machines), and it chokes when you try to move/copy/delete large files.
Slower at what? Access times? Add another server, it's not like you have to tell the clients. Write times? I don't know about that, I wouldn't want to run a database off the thing, but that's not what it's for. I have no idea what you're talking about regarding it choking on large files. I haven't seen that.
I tried it for a month before it completely corrupted it's own partition and I switched back to NFS and Samba.
How exactly did it corrupt its own partition? I've never seen such a thing. Perhaps you did something you were not supposed to do (like anything in its own partition).
I can't wait for the day when these problems are but a memory and such a system works flawlessly.
There have been some *very* large AFS installations for years (MIT, CMU, etc...). I wouldn't think that would be the case if such problems were common.
CGI in-process, using mod_perl or mod_caml, with database connection caching.
(Obviously? Surely no one in 2003 would be advocating forking and connecting to the database?)
Well, that's pretty much what CGI means. The CGI specification includes details like commandlines, environment variables, stdin, stdout, etc...
When I say a well-written CGI will be slower than a well-written servlet, I'm referring to a CGI as defined in the cgi specification. mod_perl is not used for writing CGIs, it's used for making CGIs that use CGI.pm run more quickly. CGI.pm makes a reasonable abstraction layer ehre that allows one to write something written properly to work either way.
There is also FastCGI which overcame some of the limitations of CGI, but applications typically need to be written differently to operate this way.
So, no, it's not really obvious when you use terminology that has a specific meaning when it's not the meaning you're trying to convey.
Firstly I've written mod_caml which is, you'll be disappointed to know, an interface to the Apache API from Caml.
I'm a little confused by the point of this statement. Why am I disappointed to know this?
Secondly, OCaml isn't just a compiled language.
Well, no, it's got a repl, but that would seem to defeat the purpose of the static typing.
Thirdly, if you'd ever written a website you'd know that queries on the database dominate. Interpreted, compiled - it makes no difference.
You left out the word ``badly'' in the first sentence. Putting a lot of the work on the DB limits scalability dramatically. I had to deal with these issues at my current job. Everything that wanted data, no matter how static, would request it directly from the DB at the point it needed it. We had horrible scalability problems and couldn't get a DB server big enough to handle our load about a year ago. Now, with approximately 8-9 times more traffic, things are typically 12 times faster.
A well-written CGI will be less efficient than a well-written servlet, especially under load.
This is plainly wrong.
It's my experience, mostly due to the ability to pool and cache data, as well as perform asynchronous parallel processing even after the client disconnects, freeing resources for the next guy. It also helps to be able to perform a good deal of initialization before the first client talks to you and holding onto that state for a while rather than trying to figure out what to do every time a client makes a contact with you.
I mean, just from a syscall point of view, I don't have to fork/open/read/close/connect/close to figure out where my database is and connect to it. Not to mention the overhead of actually parsing the config and authenticating with the DB.
Why do you believe that a CGI is more efficient?
EJBs, and Java in general, are almost always entirely the WRONG approach to producing websites.
EJBs usually, java, no. The servlet architecture is one of the best things to happen to web development as far as making highly scalable web applications.
To make an efficient site, use a scripting language like Perl [or OCaml, but I declare an interest in that], write CGIs, use mod_perl to make it run efficiently, and where you want to optimise, put your logic into stored procedures. Templating and SSIs are also useful.
This is amazingly wrong.
First, OCaml's a compiled language, not a scripting language.
Scripting languages do not make a site more efficient. They might make the developer prototype more efficiently, but they aren't going to run more efficiently than something that's compiled, and in many cases, they'll provide you with surprising results later on.
Even then, I often write my struts actions in python for development. I've got a struts action that allows me to write them in python or bsh, which saves a ton of development time at the cost of runtime efficiency. Being able to write a two-line struts action is nice, though. These should be ported to java before I expect to them to handle load, though.
A well-written CGI will be less efficient than a well-written servlet, especially under load.
mod_perl is great if you can stand to write perl, and can do it carefully, but there are plenty of problems with doing this.
Putting your logic in a stored procedure will give you the opposite of scalability. The database is generally the most expensive resource in an application, and is the most difficult to distribute. You want your logic as far away from this as you can possibly get it.
Not as many third party specifications to learn. I remember having to learn Struts, Ant, Tomcat, and then Sophia after learning JSP - what a pain in the ass.
You would consider it a feature that there aren't third-party tools to improve development and deployment?
I have no idea what Sophia is, but I used java for a long time before hearing of struts and ant (you know, you can use Make with java). Struts takes the generic specs and makes things a lot better. They're both optional. Like many other misguided souls, I've written apps completely in jsp as well.
Third-party options that fit into standards, make things better, but are not required are an advantage, not a disadvantage.
Tell me, does your SliMP3 understand the format that music is on on the raw CD?
Yes it does
Weird, I upgraded mine a couple of days ago, and it still won't play anything but mp3s.
However, if I run my server on a Mac, it'll recode AIFF, WAV, and AAC on the way to the slimp3.
I run my server on Solaris, though, so the music I buy from iTMS gets converted on my powerbook before moving over there.
Well then how about the "open source guys" shoudl stop posting articles about how much better linux is than windows. After all,w e wouldn't want ot make any Windows user's life easier, even if it did mean liberating them from free software.
I didn't mean to imply that we don't want Windows users' lives to be easier. The amount of effort it takes to suggest an alternative platform is far less than the amount of effort it takes to make sure my software works on one I consider inferior, though.
By your description, those Apache HTTP server folks are a bunch of seelouts, because I'm running their product on this very Windows XP box. Those bastdards! Who do they think they are making this Windows user's life easier? And they're not alone. Many Java, Python, Perl, etc. oppen source projects are also cross-platform. They're all readily cross-platform.
Windows users took the time to port Apache to Windows. Same for any other open source app that got ported to Windows (java does *not* count). If I don't use Windows, why would I go out of my way to make sure you can? I'll take your patches if they're good and don't conflict, but I'm not going to waste my time on something I'll never use.
So I know you said you weren't trying to be rude. It's just that your point-of-view (windows users are evil and should be left to rot untilt hey take the leap of faith that is Linux) conflicts with other views (we need to hurt Microsoft by taking away their customers by any means necessary).
Anyone who has any goals remotely like this is hopefully going to be making money from them. My goal is to write good software that serves me well. If it servers others well, all the better.
Yes, but gradually and comfortably. If open source guys could focus on cross-platform stuff, it would be a smoother transition. I could switch out my PIM now, for example, and take it with me when I'm ready for the Linux plunge. At least compatible data formats.
We open source guys aren't working for you. Personally, I have no interest in writing any software to make people's lives any better when they're on Windows. If you want this, you do it.
I'm not trying to be rude or anything, but you're talking about free software. If your only contribution is telling them that you want them to go through extra effort to make sure their software works in Windows, I doubt you'll get far.
As you say, you've been having problems lately.
:)
My RSS feeds have broken randomly for as long as I've had the thing up. It's given me the opportunity to come up with a really robust design for it, though.
There's a really handy module called "Fatal" which you can use to make any existing function throw an exception if it returns a false value. For example:
use Fatal qw(open close);
This is very informative and something every perl programmer should know and use.
I, however, will be sticking to languages that don't require me to remember to mark every function that might fail as something that should throw an exception on failure and will just do it by the way stuff in the language is designed. I don't want to have to remember the way to get DBI throwing exceptions, IO stuff throwing exceptions, etc...
You're misinformed. I use exceptions with DBI. Just pass it the RaiseError parameter.
:)
Behind is probably more accurate.
Is there a RaiseError parameter for open(), read(), write(), etc... ?
My Perl code uses exceptions extensively. It's not necessary for me to check return codes. I think you are generalizing based on one way to write Perl code.
Perl's file IO, DBI, etc... make no use of exceptions. You have to build your own abstractions to do this. Python, ruby, java, ocaml, (etc...) use exceptions at the lowest level available to the programmer.
That's my point.
Slashdot's code is not very elegant. This is not Perl's fault.
I disagree here to a degree. Languages have cultures and idioms that are built around them. If a language makes it easier to do something in a bad way, then it's most likely to be done in a bad way (or it'll be hard to work with).
For example: Perl, like C requires you to check results of most things you do to verify they worked. That's a ridiculous way to write anything of any complexity. If I say something should happen, it should just happen. If it can't happen, *then* let me know about it. Good code in a language that uses exceptions natively looks like ``bad'' code in a language that requires you to do the work yourself...meaning the programmer will likely express what he wants to happen and then move on. If exceptions are a core part of the language, the application will go to an exception handler as soon as something ``goes wrong.'' You have to specifically prevent this from happening.
Compared to having to specifically validate every operation you do and plan a path out even for really unlikely cases, it's a lot easier to write reliable applications in langauges like python, java, ocaml, etc...
I would say that caching search results in the session is a big mistake. First, what if the user opens multiple browser windows? They will get crazy results if they try to run multiple searches and page through them, and this is a fairly common scenario for most sites. I think you'd be much better off using a file-based search results cache with the search criteria as the key (rather than the session ID).
Well, likewise, I could pass the search ID around through all the pages if I wanted to deal with that scenario. There's no file IO required for every re-sort.
MyISAM tables have no transactions, so you are basically talking to an in-memory multi-threaded daemon over a local Unix domain socket.
UNIX domain socket means the machine with the app server has to be running the database. It also means that there's no failover for the session. A DBM would be better at this point (map key to structure, read and write structure at request/response time).
Programmers like other professionals need to establish a sense of professional elitism. PHP is a language that just about anyone can use, and when you have something that just about anyone can do, then you won't get the big bucks.
It's not so much elitism as it is experience. I work on project lifetimes these days. I want most of the work up-front so I can move on to other things. Whatever little savings PHP might get me up-front is of little value over the lifetime of the project.
The end result, PHP/MySQL is what people use when they want to get a job done, Java/XML is what you use if you want to build a career.
That sounds like consultant mentality. It makes sense if your goal is to produce a working model that will look good at the end of a contract, after which you will never see it again...and who cares if it is difficult to maintain?
I just don't work that way.
I guess your information is not very important since it can be wiped out by a power down or crash between the confirmation and the asynchronous background write.
In my app, I've got somewhere over a half a million clients that come talk to me every day and tell me how things are, ask what's new, etc... I track various aspects of this information in a couple different databases. If I don't save information for a guy today, I will tomorrow. In cases like this, async transactions get the user back on his way very quickly and I rarely miss a save. If I do, big deal.
I also do asynchronous saves in my photo album app (photoservlet.sf.net), but I do it a different way. In that application, there is a cache of structured image data that is used for putting up the pictures, but the image data also gets stored in the database. When a new picture comes in, I immediately structure the data and cache it for viewing, and then write a couple of records indicating the data has arrived. Within a few seconds, a thread will notice the changes and begin storing the image data into the DB (which takes too long to make a user wait).
This is an example of asynchronous transactions done safely while still giving the appearance of a faster application.
It's VERY hard to go faster than MySQL with MyISAM tables for this kind of simple shared data.
Sure, for small numbers of servers sessions and requests. My application server farm contains eight systems. Intelligent routing means that you're most likely going to go to the server that has your session state in a Map in memory. When it's a single map lookup to find your session, and then a map lookup for anything out of your session, that's pretty much as fast as you can theoretically get.
Replication of the session involves the container serializing the Map and passing it to one server in the cluster that is defined as its secondary. This means your session is replicated once so that if your master server fails, the session routing will take you to the secondary server (and if it fails, you lose your session).
Sometimes, you need large sessions, though. My application has a search which can return, at most, 200 results. My search UI allows you to page through those results (randomly or sequentially), change the sort order, etc... Any operation (after the initial search) is nearly instant. It's also consistent. You don't hit the next page and suddenly see duplicate results, or miss results because the source data changed.
In this example, a larger session makes everything better. Hitting a DB every time someone wants to go to page 2, or sort by last name or whatever would be slower, regardless of what type of table you use in your mySQL DB.
(OT: upon trying to submit this message:
500 Internal Server Error
An internal server error occurred. Please try again later.
)
Perl seems to scale as well--it runs a very busy site [slashdot] I frequent with few problems.
I've been having a great deal of broken pages lately.
I also have been having a lot of problems with the RSS feeds lately.
Overall, I like using slashdot as an example of why mySQL and perl are bad ideas for busy sites.
Any language can be used to write bad code, but I've rewritten really perl projects (2M line range) that were impossible to maintain into java (for example) applications that were not only easier to manage, but performed better.
Whether raw perl is faster than raw java, who knows or cares? When I want raw speed, I write apps in ocaml (or C if I need slightly more speed). When I want to prototype something quickly, I write apps in python. When I want to build a large scale application, I use java (and python for parts). With a proper design, going from one application server to two doesn't double the strain on my database server (not even close), but usually doubles my capacity. It also doesn't require a rewrite of the app.
Then I start making things happen asynchronously with threads and message queues. These days, my apps are looking more like mainframe apps from performance monitors. We maintain a pretty high load here, and I watched it triple during some event for a few minutes. Processing speed was constant due to surge protection I was able to make using a simple thread and a linked list. For our most common type of database work, there is no more than one insert/update occuring per application server instance. That makes such a huge difference.