I don't know about Apache but those rules in IIS would be bad as it would 404 if you add a querystring. Do those work with querystrings?

What would be the correct way to do them because I do notice a ton of 404s in the logs.

Do you mean if it works if I don't rewrite them and type them out normally? If so yes, both work fine.

you have two rules where the matching regex is identical: ^(.*)/(.*)$. that obv can't work. which one wins could depend on order or be random, but it's never going to do what you want.

Something like this:

<rewrite url="~/construct2(\?.+)?$" to="~/construct2.aspx$1" processing="stop"/>

Does it on IIS

If I write out the first part (the "m" part) manually so the regex for both the blog and photos page are different it still doesn't work.

So basically replace every instance of (.*) with (\?.+)? I know nothing about IIS heh, but I'm guessing processing=stop is basically the L flag and the NC flag is to make it case insensitive.

Heres a question that seems simple enough, but I haven't been able to get a straight answer for. Let's say you have a website located at mydomain.com. You have a single server associated with that address but you want to spin up more servers to handle the load. How do you add additional servers all the while keeping it under that same domain (i.e. not resorting to using sub-domains for each server)? Does the answer change if each user needs access to unique data stored on a single server and you can't replicate their data? This couldn't be as easy as defining a sub-domain rewrite rule in apache, could it?

No, it's not that easy. You need to figure out how to do load balancing. By that point, you will have one badass site, so I'm sure you'll find the money to get it done. It's very complex.

Why can you not replicate the data? How would having addition servers help if they have different data?

I researched something similiar at one point and I remember looking into round robin dns. From what I remembered it seemed decent based on our budget (free) though i believe a hard ware load balancer is much more ideal solution. Hopefully someone else can confirm / deny...

Note: I didn't implement anything just did a few hours asking very smart people and weighing options. It was obviously cost prohibitive for the company I worked at before... Couldn't afford a second server even

it depends a lot (entirely?) on how complex the stuff you're trying to serve up is. if you've created the funniest lolcat in the history of lolcats and just want everyone on earth to be able to see it, that's pretty easy. if you're facebook and you have millions of photos, statuses, etc. being updated and viewed all the time, that's hard.

Sounds like time to go to Amazon AWS.

Replicating the data would be cost prohibitive. Serving user data is computationally intensive on the backend as well, so being able to split that out effectively while keeping it under one domain is the goal. One other important factor is while I'm not able to replicate the data, the data is completely stored in MySQL databases which can be set up for remote access by any other server in this configuration. While I haven't tested it in a while, the loss in efficiency of querying data on remote servers is not too bad. At this point the major bottlenecks appear to be in the PHP i.e. assembling the data, sending and receiving the data, and rendering on the client-side.

Here's a quick 20 second demonstration of what we're trying to do: http://www.youtube.com/watch?v=Sq5bbi41nfI

We're on Rackspace. They offer a load balancing service, so I'm going to go ahead and check that out and see if it suits our needs.

Thx

running the database on a different box from the web server would be a good first step. apache will be able to use the extra memory (may require configuration) and be able to handle more traffic. there are other things you'll want/need to do before you can scale to a situation where you'd use a dedicated load balancer.

(this is assuming your application is truly constrained by your php application and not your database but based on your demo that seems to be the case.)

If it's PHP, you can consider hip-hop for PHP, Facebook's interpreter and compiler for PHP which I use for my baseball simulator (Alekhine's Gun).

But it might be a database issue with all those hand histories, in which case you might want to think about optimizing your persistent data store. Are you using a NoSQL solution like MongoDB?

ETA: Never mind, I can't read. MySQL might not be the best solution for this type of application. Have you considered key-value stores? Even if this isn't the limiting factor now, it could very well be in a short period of time.

Thanks. This fits with the other advice i've been getting.

I would be very interested in finding out how hard it is to set this up.

Admittedly I don't know a lot about NoSQL. So far i've made due with aggressive indexing.

This certainly worth a shot.
I know his db backend quite well, and it isn't particularly well geared to key-value (though i'm curious about relational->key/value approaches)

Most of the data is pretty static though.

kyle,

imo he only needs nosql if he needs web scale. does he need web scale?

I use Ubuntu 10.04 LTS for all of my production web servers that I manage myself (which is a grand count of 2 at the moment). Here's a simple guide to follow:

https://github.com/facebook/hiphop-p...untu-10.04-LTS

I've used CodeIgniter as a framework for PHP and it doesn't play well with hip-hop; most frameworks don't. However, I've rewritten most of the code to work as simple object-oriented PHP without much trouble. (I recently upgraded to 5.3 for all my legacy apps and plan on leveraging the asynchronous functions of it; I don't know how well these play with hip-hop but I imagine it's not terrible.)

Give it a shot, though for a large application you might need to consider hiring a part-time server admin to walk you through setup and maintenance. All costs considered, it might be worth it.

RE: tyler, I think if you have a moderately successful data-intensive application that is constantly calling up hand histories (just another name for a "document"), a persistent data store is gonna get taxed a lot. memcached might be a simple solution for the most commonly-called data objects (easy to setup on any Linux box and the PHP extension is simple to use), and it is well-suited for scaling horizontally like they're interested in, but a NoSQL solution might be something they need to investigate eventually. Getting started with MongoDB or Redis or whatever for a fun side project might be worth the time investment now, even if they hire a contractor later.

I'm not really well versed in any of the NoSQL technologies, but is querying them as easy as a relational data store? For example would it be easy to ask MongoDB to give you all hands played between dates X & Y filtered for 5-6 players where UTG raised and you called in LP? That kind of stuff seems like relational db bread & butter to me

Yes, that should be fine imo.

If it starts running slowly you have 2 options:
- Throw money at it and get a better computer
- Denormalise it, as it's historic data there's no reason with each hand played you cant have bools named things like "UTG Raise and I call", "UTG+1 Raise and I call" etc. It would make complex queries a lot faster as the processing for that data would be calculated on insertion and not search.

Either way, don't optimise for performance until you have to (it's running too slowly). I would design it as a fully normalised system at first.

haha. in case anyone didn't get the reference

hello everyone!

learning about functional programming and somebody said

' if you get good at Haskell and work in industry, you're *going to* get a six figure salary.' i would ask him why this is but he may be very biased as he teaches the course etc....

but why is it such a well paid job? (only had one lecture in it) and is this true?

The key part there is 'getting good'. I don't know anything about Haskell. But if your the top of the game in any programming language you're probably guaranteed a very good salary. Like anything else really.

If employability is what you're after, Haskell is low on the list of languages I'd be learning.

It's a cool language for sure though.